傳遞性導覽

這個原則又稱作「迪米特法則」(Law of Demeter) 或 「撰寫出害羞的程式碼」(Writing Shy Code)。

通常，我們不希望讓某模組瞭解其合作模組的細節。

也就是說，當模組 A 與模組 B 合作時，模組 B 也與 模組 C 合作，這時我們並不會希望讓模組 A 也了解模組 C 的訊息。可是當我們使用類似 a.getB().getC().doSomthing() 時，就會使得資訊被傳遞，也因此要避免這樣的內容。

除了保持模組間只知道必須知道的資訊外，這個原則也幫助了我們對程式進行重構。因為當我們未來需要在 B 與 C 模組之間加入模組 D 時，將被迫找出整個系統的 a.getB().getC() 敘述，並改為 a.getB().getD().getC()。

違背慣例

所謂慣例，可能是一般普遍撰寫程式的標準或慣例，抑或是團隊內部自己的規範。在一個程式裡，團隊成員應遵循共同規範，包括程式碼撰寫風格、宣告變數位置及命名方法等等。這些慣例或標準雖然並非強制的規定，但當我們共同遵循時，會使程式的被閱讀性及詮釋意圖的能力都更加提升。

在命名慣例上，團隊常會因特定專案而發明屬於自身的命名系統，Eric Evans 稱其為「普及語言(ubiquitous language)」，而當專案中出現這樣的規範時，我們就應該廣泛地去使用與遵循其詞彙，來幫助專案呈現更整潔的狀態。就如同分享編排文章的末尾所述，我們希望能維持統一的軟體風格，好使專案能夠更容易被閱讀。

而提到慣例時，值得留意的是結構勝於常規，因為結構具有強制的設計特性，會比非強制力的慣例更加具備約束性。

例如，一個良好列舉命名的 switch / case，仍不如有抽象方法的基底類別。因為基底類別會強制實體類別實作出所有抽象方法，而慣例則無法約束撰寫者每次都使用相同方法去實作 switch / case 敘述。